========================================================================= INFO-ATARI16 Digest Fri, 2 Mar 90 Volume 90 : Issue 275 Today's Topics: Bug in TURBO-C V1.0 Calling callgulam from TC HD back-up & vault Need Help with 5.25 floppy STE DMA sound (documentation posted) (3 msgs) Supra's extended partitions and tos 1.4 ---------------------------------------------------------------------- Date: 2 Mar 90 10:39:54 GMT From: sdcc6!sdcc10!mce@ucsd.edu (Mark Edwards) Subject: Bug in TURBO-C V1.0 Message-ID: <8098@sdcc6.ucsd.edu> In article <1990Feb21.204744.560@agate.berkeley.edu> ericco@stew.ssl.berkeley.edu (Eric C. Olson) writes: #roland@cochise.pcs.com (Roland Rambau) writes: #>hcj@lzsc.ATT.COM (HC Johnson) writes: #>->> > #define MAX -32768 #>->> > main() #>->> > ? #>->> > printf("1: %d\n", MAX); #>->> > printf("2: %d\n", (int)MAX); #>->> > ? #>->> #>->> This is not a bug, its a feature. MAX is not a number, its an expression. #>->> Thus, the evaluation of MAX is a long int. The first printf only prints #>->K&R specify that constants are int's. Not a long int. # #Like I said "MAX is not a number, its an expression." There is an integer #in the expression (the number 32768). But there is also an operator (the #unary minus). This makes MAX an expression, not a number. Thus the real #question is what does K&R say integer expression are evaluated to? I #don't have K&R handy, but I believe it says long ints. # K&R, second edition, section A8.2 type specifiers offers these useful quotes: 1. If the type specifier is mission from a declaration, it is taken to be an int 2. The signed specifier is useful for forcing char objects to carry a sign; it is permissible but redundant with other integral types. 3. At most one of the words long or short may be specified together with int; the meaning is the same if int is not mentioned. IMHO, MAX is a constant expression. Since its type is unspecified, it is an int. Since it is not specified as unsigned, and is an integral type, it is therefore a signed type. Together the conclusion that MAX is a "const signed int MAX" when all the defaults are considered. K&R say nothing about the issue of long or short. Neither does section A7.4.5 on the unary minus operator. The issue of long or short is probably best resolved in the traditional manner i.e. an integer is the size of the native machine word. This is 32 bits on a 68K. A 8086 or 286 would be 16 bits by the same tradition. The native int on the 68K is then a long int, and on the Intel it is a short int. The expectation that short int means 16 bits and long int means 32 bits is still meaningful. The answer to the question is machine architecture dependent. For purposes of the discussion at hand, the 68K compiler should treat MAX as a signed 32 bit integer. #Eric #ericco@ssl.berkeley.edu # -- Mark C. Edwards voice: 619/586-2204 Associate Systems Analyst unix: mce@pbsdts.pacbell.com Matt 3:16-17,Acts 7:55-56,*John 8:17-18,*John 14:28,*Mark 13:32, *John 20:17,*Matt 12:31-32,*John 17:20-23 (* Red letters) ------------------------------ Date: 2 Mar 90 08:46:28 GMT From: mcsun!sunic!tut!av74381@uunet.uu.net (Vesterinen Arto Tapio) Subject: Calling callgulam from TC Message-ID: <3140@tutor.tut.fi> In article bammi@dsrgsun.ces.CWRU.Edu (Jwahar R. Bammi) writes: > your example is correct. the reason it does'nt work from Turbo C >is that Turbo C passed the arguements in registers by default, while >gulam is expecting them to be on the stack (like the normal C stack >frame conventions). (is there a option in TC to do this??) > There is a TC compiler option Standard stack frames. I tried it out, but I still get two bombs, oh well... :-( ------------------------------ Date: 1 Mar 90 12:57:47 GMT From: umich!sharkey!cfctech!teemc!ka3ovk!irscscm!root@CS.YALE.EDU (Admin) Subject: HD back-up & vault Message-ID: <1990Mar1.125747.17839@irscscm> I have always been leary of using a hard drive back-up program and have always done it by hand. But now I've decided to change my ways and have begun to use vault. It seems to work very well so far but I haven't spent enough time with to be sure yet. What is everyone else's opinion of vault? One thing that has been happening to me is that occasionally my system locks up upon selecting an item from the drop-down menu of vault. When selecting QUIT, 3 bombs appear before the system locks. Has this stuff been happening to anyone else? Is it possible I got a bad download of vault (though it uudecoded and un-arced with no errors). Marshall Lake mlake@irscscm.UUCP ------------------------------ Date: 2 Mar 90 16:16:01 GMT From: jensen@cod.nosc.mil (Layne K. Jensen) Subject: Need Help with 5.25 floppy Message-ID: <1808@cod.NOSC.MIL> I have finished (?) installing a 5.25-in floppy drive on my 1040ST, but have run into what to my untrained eye appears to be a catch-22 situation on boot-up. I haven't seen this discussed before, so I think there must be a simple explanation/fix. Just for the record, this is an Epson drive. If the floppy head isn't near track 0 at boot time, there is a vibrating sound from the drive, and it appears that the drive is trying to seek to track 0, but not succeeding, presumably because at that point the step rate hasn't yet been slowed down to 6 msec. Therefore the drive doesn't find track 0, the computer doesn't see the TRACK 0 signal asserted, and the computer comes to the conclusion that there is no drive B. Even though the program to set the seek rate is now executed from the AUTO directory, it doesn't matter, as the computer has given up. So I can't run a program that parks the heads on drive B. And on re-booting the whole problem repeats itself. What do you do about this situation? At this point my drive is in the open, so I manually reset the head before powering up the drive, but once it is in its case that won't be an option. Is there a program available to park the head before turning off the drive? (I know I'll forget to run it half the time.) How about a program to tell the computer that there really *is* a drive B after all, stuffing some information into a magic memory location? I don't have any documentation that would tell me about such locations. Do other types of drives manage to find track 0 even without the step rate change? Any help this would be appreciated. Layne Jensen jensen@nosc.MIL Naval Ocean Systems Center ...!sdcsvax!noscvax!jensen San Diego, CA -- Layne Jensen jensen@nosc.MIL Naval Ocean Systems Center ...!sdcsvax!noscvax!jensen San Diego, CA ------------------------------ Date: 2 Mar 90 04:57:49 GMT From: zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!uvaarpa!murdoch! astsun8.astro.Virginia.EDU!gl8f@tut.cis.ohio-state.edu (Greg Lindahl) Subject: STE DMA sound (documentation posted) Message-ID: <1990Mar2.045749.24902@murdoch.acc.Virginia.EDU> In article <1990Mar1.183809.4264@bath.ac.uk> exspes@bath.ac.uk (P E Smee) writes: [ about the abacus gem books ] > >Does this mean they've fixed them, then? Well, my experience with the Abacus GEM book (which is better than their others, I think) is that the errors in the 1st edition fall in 3 areas: 1) obvious typoes, easy to correct, some only after a little experimentation :-( 2) errors which are copies of errors in DRI's documentation (which Atari sells in its devkit) 3) failing to explain which calls are only useful when GDOS is around. I've seen several people asking questions here who obviously tried to read the manual and were very confused on this score. As such, I've had reasonable success using it for some small GEM stuff, although I never tried anything with GDOS. I haven't read the 3rd edition, but I believe a review was once posted here? I also don't know if any of the GEM books have useful tricks like the little routine that intercepts right-button events and turns them into left-button events. I'd also love to see someone do a SANE binding for GEM calls that passes pointers to structures instead of a bunch of variables that everyone keeps in structs anyway. I managed to cut the size of the GEM demo program source in half that way, and the object code for the demo itself (sans bindings) shrank 35% or so. Less bloody stack-pushing and popping for stuff that's going to get popped and shoved into arrays anyway. >My present favorites are the 3-volume Compute! series (one book each on >AES, VDI, and TOS) and Katherine Peel's 'The Concise Atari ST 68000 >Programmer's Reference Guide' -- but not the first edition which was >lacking any form of index. Indexes do come in handy. Greg Lindahl gl8f@virginia.edu Astrophysicists for Choice. ------------------------------ Date: 1 Mar 90 15:35:27 GMT From: zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!asuvax!hrc!force!covertr@tut.ci s.ohio-state.edu (Richard E. Covert) Subject: STE DMA sound (documentation posted) Message-ID: <48ef7017.14a1f@force.UUCP> In article <37193@iuvax.cs.indiana.edu>, kclenden@silver.ucs.indiana.edu (Kevin Clendenien) writes: > > As far as having to spend a couple of hundred bucks just to get > information on your machine, this is no different than IBM, Mac, or > Amiga computers. When you buy IBM and DOS, do you get a technical > reference manual? NO! Sure it's available, but at a cost. This > same scenario is played out with both Mac and Amiga computers. You > can find information on the Atari line of computers without having > to become a developer. But, just as with the above mentioned > computers, you will have to pay for it. I wish information was > free, but we all know that just ain't so. Knowledge makes the world > go round. Not just in the computer field, but in every field. Horse pukey!!! Apple gives much better support and much of it is free!! Just read the mac.binaries newsgroup. Apple is always posting Macintosh Technical Notes there (which unfortunately ar BinHexed and can't be read on UNIX machines!). Just in the last couple of days Apple posted over a dozen Technical Notes covering various aspects of System 7 and Hypercard and other subjects. It makes me jealous to see some much technical information being so freely deseminated!! And Atari Corp has the nerve to criticize a magazine reporter for publishing programming notes on the STe! Geez, with Apple, you would have seen the Mac Tech Notes BEFORE a reporter had a chance to "link" them. Just goes to show you the difference between a REAL COMPUTER COMPANY and A GAMES MACHINE COMPANY!! And as far as buying Tech Books, there are hundreds of programming and technical and self-help books for the Macintosh. Except for Turner's self-published books, there hasn't been a new ST book published in the USA for 2 years!! Argh!!! And Atari Corp has the nerve to criticize a reporter for publishing notes about an Atari computer (actually the STe is better classified as a games machine!. I don't need stereo sound for DTP! ). -- Richard E. Covert, Lead Engineer of Software Tools Group AG Communications Systems, Phoenix AZ (602) - 581-4652 TCP/IP: covertr@gtephx UUCP: ?ncar!noao!asuvax | uunet!zardoz!hrc | att?!gtephx!covertr ------------------------------ Date: 1 Mar 90 15:51:00 GMT From: cs.utexas.edu!asuvax!hrc!force!covertr@tut.cis.ohio-state.edu (Richard E. Covert) Subject: STE DMA sound (documentation posted) Message-ID: <48ef7e01.14a1f@force.UUCP> In article <1990Feb27.230234.8875@murdoch.acc.Virginia.EDU>, gl8f@astsun8.astro.Virginia.EDU (Greg Lindahl) writes: > I have 2 books which tell me just about every software question I've > had about the ST. Cost? $45. Sometimes I think I live in a different > universe from everyone else. If you buy a copy of Mark Williams or > Laser C, you get an excellent GEM manual. You can also mail-order > books about GEM if your dealer doesn't carry them. > > So what's the complaint? I keep on asking what people don't like about > current ST books. I haven't seen (yet) a single person who has > actually read the 3rd edition Abacus GEM book, or one of the other > good GEM books, and thought that it had lots of errors. Although some > dealers don't carry them, they are available mail-order, and you can > find ads for them in magazines. > > Where's the beef? > > -- greg > Greg Lindahl > gl8f@virginia.edu Astrophysicists for Choice. Where's the beef?? Well, for one there is the still the fact that no NEW ST book has been published in the USA for 2 years. And the fact, that even Greg admits, that you can't buy *ANY* ST book in the major bookstores. Just ask someone in a Waldenbooks store and you will either get laughed at or they will mutter something about the Atari just being a "Games Machine" Greg, are you on a paid retainer by Atari Corp?? I have *NEVER* seen you take a stand criticizing Atari Corp on *ANY* matter?? If you aren't, you should ask Atari Corp to pay you !! But, you are correct, the Mark Williams C manual is a great source of C code for GEM AES/VDI. But where do you go for info on programming for GDOS?? GDOS is one big black hole as far as Atari Corp is concerned. It isn't covered in any C book that I have. And programmers are all having problems writing GDOS printer drivers. So, where's the beef?? I would answer "In Sunnyvale!!" (At least there's lots of beef by-products emitting from Sunnyvale judging the strength of the odors!). Opinions are my own, but are for sale. Send MegaBucks. -- Richard E. Covert, Lead Engineer of Software Tools Group AG Communications Systems, Phoenix AZ (602) - 581-4652 TCP/IP: covertr@gtephx UUCP: ?ncar!noao!asuvax | uunet!zardoz!hrc | att?!gtephx!covertr ------------------------------ Date: Fri, 2 Mar 90 15:08+0100 From: Ritzert%DMZRZU71.BITNET@Forsythe.Stanford.EDU Subject: Supra's extended partitions and tos 1.4 Message-ID: <900302140852.561040@DMZRZU71-UNI-MAINZ--GERMANY> Jim Hurley wrote: >I just upgraded to TOS 1.4 and was wondering if I can >now have a partition size greater than 16Meg. My SUPRA >utilities will let me make one, but complain that GEMDOS won't >support it. Thanks in advance. Ignore this message. It works without problems under *tos1.4*. I am using Supra's software with 23 Meg partitions without having any problems. The older tos-versions, however, cannot handle Supra's extended partitions. Hope this helps Michael Ritzert mjr@dmzru71.bitnet ------------------------------ End of INFO-ATARI16 Digest V90 Issue #275 *****************************************